Highly scalable internet protocol-based communications system

ABSTRACT

A highly scalable Internet Protocol (IP) based communications system which provides voice and other communication services to end-users. The instant system incorporates a unique architecture which simplifies scaling of services to hundreds of thousands and even millions of subscribers. The instant system architecture includes a means for directly connecting a plurality of peered service providers thereby obviating the need to move the communications across the PSTN. By bypassing the PSTN, the instant system can leverage the advantages of IP-based networks in meeting subscriber communications needs such as, without limitation, quality of service, service up-time, and advanced feature sets. Bypassing the PSTN also allows the peered partners to negotiate communications rates between themselves, without incurring PSTN carrier fees.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 12/109,908, filed on Apr. 25, 2008, nowpending, which is a continuation of U.S. patent application Ser. No.11/857,290, filed Sep. 18, 2007, now abandoned. Each patent applicationidentified above is incorporated here by reference in its entirety toprovide continuity of disclosure.

COPYRIGHT NOTIFICATION

This application includes material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent disclosure, as it appears in thePatent and Trademark Office files or records, but otherwise reserves allcopyright rights whatsoever.

FIELD

The instant disclosure relates to the field of telecommunications, andmore specifically provides a highly scalable system and methods throughwhich Internet-based communications generally, and Internet Protocol(“IP”)-based telephony specifically, can be effectuated.

BACKGROUND

Conventional Voice over Internet Protocol (VoIP) system architecturesare tightly coupled to the legacy Public Switched Telephone Network(PSTN). Devices known as “media gateways” send or transfer a call from apacket-based network carrying the VoIP data, such as the Internet, tothe circuit-based PSTN network. These media gateways focus ontranslating signaling information, call routing information, and voicepayloads between the two different networks and relaying suchinformation between the networks. Media gateways have a combination ofcircuit switched technology and packet switched technology, and theirinternal structure is typically architected around call routingtechnology based on elements of the legacy PSTN system.

Because these media gateways are tightly coupled to the PSTN, theirimplementation necessitates a highly distributed architecture with manyattachment points to the PSTN. In fact, conventional VoIP architecturesoften use the PSTN as a backbone to connect these distributed attachmentpoints together.

SUMMARY

Unlike conventional VoIP architectures, the instant disclosure isdirected to a highly scalable IP-based communication system. In anembodiment, the insertion of a circuit-switched network communicationsoriginating and terminating onto IP-based networks is avoided, therebyallowing the communication to leverage IP-based capabilities andoptimizations, including, without limitation the use of advancedbroadband codecs, incorporation of rich media content, and the use ofadvanced real time interaction and monitoring capabilities.

Some embodiments disclosed herein are directed to a scalablearchitecture capable of serving hundreds of thousands, and even millionsof subscribers and their related devices. Unlike conventional VoIParchitectures which can only handle a limited number of subscribers andthe Session Initialization Protocol (“SIP”) registrations (such as, forexample, the SIP registrations defined in the Internet EngineeringTaskforce's Request for Comments 2543 or other related and/or successordocumentation) generated by their devices, some embodiments disclosedherein implement a scalable architecture which allows, for example, SIPregistration and registration retransmission behavior, which isnecessitated when network anomalies or other problems arise, to behandled without degrading system performance. Some embodiments can alsoleverage the architecture set forth herein to facilitate management ofthe various subscriber devices, including, without limitation, theimplementation of changes and improvements to such devices such assoftware and/or firmware updates

Some embodiments facilitate the querying of multiple E.164 NumberMapping (“ENUM”) trees (as defined in Internet Engineering TaskforceRequest for Comments 3761 and other related and successor documents). Atpresent, the ENUM query module that ships with SIP Express Router(“SER”), available from http://www.iptel.org, and most otherconventional VoIP software assumes the need for querying one, and onlyone, ENUM tree. By contrast, some embodiments disclosed herein supportsimultaneous or nearly simultaneous querying of multiple VoIP peeringexchanges, each with their own private ENUM tree.

Additional features and advantages will be set forth in the descriptionwhich follows, and in part will be apparent from this disclosure, or maybe learned by practice of the invention. The objectives and otheradvantages of the invention will be realized and attained by thestructure particularly pointed out in this written description,including any claims contained herein and the appended drawings.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the disclosed highly scalableIP-based communication system.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the disclosed highly scalable IP-based communicationsystem and are incorporated in and constitute a part of thisspecification, illustrate various embodiments and, together with thedescription, serve to explain the principles of at least one embodimentof the disclosed highly scalable IP-based communication system .

In the drawings:

FIG. 1 is a block network diagram of an architecture through which ahighly scalable IP-based communication system can be implemented.

FIG. 2 is a block diagram illustrating a traditional SER ENUM flow.

FIG. 3 is a block diagram illustrating an alternative SER ENUM flowcapable of simultaneously polling a plurality of ENUM trees.

FIG. 4 is a block diagram illustrating an alternative SER ENUM flowcapable of simultaneous polling a plurality of ENUM trees and providinga layer of abstraction between the ENUM tree architecture and a SERDirectory Proxy.

FIG. 5 is a block diagram illustrating an alternative MIFFED serverarchitecture which utilizes a plurality of MIFFED servers.

FIG. 6 is a flow chart illustrating an exemplary SIP device registrationprocess.

FIG. 7 is a flow chart illustrating a continuation of the SIP deviceregistration process of FIG. 6.

FIG. 8 is a flow chart illustrating an exemplary process flow throughwhich a SER can amend the cluster database based on SIP responseinformation received from a CCN and forward the resulting registrationinformation to a digital telephone.

FIG. 9 is a flow chart illustrating the proxy-like functionality of theSER and an exemplary manner in which the SER can handle signalingrequests generated by the CCN.

FIG. 10 is a block diagram providing an overview of an exemplary SIPdevice initial sign-up, configuration, and set-up process.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the disclosedhighly scalable IP-based communication system, examples of which areillustrated in the accompanying drawings.

FIG. 1 is a block network diagram of an architecture through which ahighly scalable IP-based communication system 100 can be implemented.The highly scalable IP-based communication system 100 facilitates theconversion of analog voice conversations, originating or terminating ata subscriber's site, into a digital format that can be communicatedacross the Internet 108 or other shared network by taking advantage of ahigh-speed data connection, such as, without limitation, thosehigh-speed data connections provided by fiber optic Internet service, orcable and DSL modems.

The analog to digital (A2D) and digital to analog (D2A) voice conversioncan be performed using a variety of tools including, without limitation,an analog telephone adaptor (ATA) 104 and a Session Initiation Protocol(SIP) phone 106. In some embodiments, an ATA 104 is connected between ananalog telephone 102 and an existing broadband connection at thesubscriber's site. ATA 104 can sample the analog voice signal receivedfrom a conventional, analog telephone 102 and convert the analog voicesignal into a digital signal format. This converted digital signal canthen be transmitted across the broadband connection to Internet 108 oranother such high speed network. ATA 104 can also receive incomingdigital “calls” via the broadband connection and convert the voicecomponent of the incoming digital call into analog signals that arepassed to analog telephone 102.

Some embodiments may employ one or more SIP-capable phones 106.SIP-capable phones 106, also referred to herein as SIP phones 106, havethe innate ability to perform the D2A conversion necessary such that thevoice payload of the digital incoming call can be converted to an analogformat that can be reproduced by one or more speakers housed within orassociated with SIP phone 106. SIP phones 106 can also include theability to perform the A2D conversion necessary to convert thesubscriber's voice from its inherent, analog form into a digital format.Examples of devices which include such innate conversion capabilitiesinclude personal digital assistants (PDA's) on which appropriatesoftware has been installed, cellular telephones, and the ATS 6011sInternet telephone distributed by America Telecom of Atlanta, Ga. Theinnate conversion capabilities of such devices allow SIP phone 106 to bedirectly connected to the broadband connection, without the need for anATA 104. In some embodiments, the connections may be accomplished viawired or wireless communications, such as those described in theInstitute for Electrical and Electronics Engineers (IEEE) 802.11 familyof standards.

In some embodiments, the broadband connection will function equivalentlywhen communicating digital voice signals, regardless of whether suchsignals originate from ATA 104, SIP phone 106, or another such device.For clarity, the term “digital phone” or “device” is used herein torefer to any device or combination of devices capable of convertinganalog voice signals into a digital format and converting digitalformatted voice signals into an analog form which can be reproduced forthe subscriber, and is intended to include, without limitation, ATA's104, SIP phones 106, and similar, substitute, or successor devices.

Digital phones generally perform pulse-code modulation (PCM) sampling ofan analog voice signal at a predetermined rate recommended fordigitizing voice-frequency signals utilizing ITU-T standard G.711.According to the G.711 standard, analog voice signals are sampled at arate of 8000 samples per second to create a digital voice signal in a 64Kbit/second bitstream. Once converted into a digital format, theuncompressed bitstream is packetized. Such packetization may compriseconverting the bitstream into packets compatible with the InternetProtocol or other related or successor protocols. Although thepacketized bitstream is referred to herein as comprising IP packets,this term is used for clarity and is not intended to limit the instantsystem to a particular packet type.

Each digital phone can have associated therewith a unique identifier,such as, without limitation, a machine access code/media access controladdress (MAC Address) such as that defined in the Institute forElectrical and Electronics Engineers Standard Number 802.3, an InternetProtocol address (IP Address), or the like which enables the phone to beindividually addressed and identified. Each digital phone can alsocomprise a database or other list of subscriber and implementationspecific information such as, without limitation, the IP address of anAccess SBC (described below) with which the digital phone is to beassociated, the telephone number associated with the digital phone, aservice provider identifier, a subscriber account number, or other suchinformation.

The IP packets are sent to the broadband connection for transmissionover Internet 108 or another such network for processing by the systemdisclosed herein. The IP packets are routed to and processed by theinstant system based on information contained in the IP packets. Asdescribed above, the digital voice payload is inserted into one or moreIP packets such that the digital voice payload can be transported to itsdesired destination. In some embodiments, these IP packets, and thedigital voice payload contained therein, are forwarded and processedthrough the instant system as they are received. Some embodiments of theinstant system may utilize the Real-Time Transfer Protocol (RTP), asdefined in Internet Engineering Taskforce Request for Comments Number1889 or similar or successor standards, to manage the transmission ofvoice, video, or other multimedia data contained in the digital voicepayload. In some embodiments, all components in the instant system cancommunicate with each other via a private IP network and utilize IPnetworking protocols.

The instant system comprises two general components, network equipment120 and back-end processing equipment and systems 160. Network equipment120 is primarily responsible for facilitating the digital callsthemselves. Back-end processing equipment and systems 160 allowsubscribers and administrators to control account settings and access,allow administrators to control network equipment 120, handles billingand other such business services, and the like. The description of theinstant system will begin with a description of network equipment 120.

In some embodiments, voice calls to or from a subscriber are routedthrough one or more centralized server centers. Although describedherein as though the various components of network equipment 120 areproximate to each other, it should be apparent to one skilled in the artthat the various components need not be physically proximate.

In some embodiments, a subscriber-placed call can be initiated by thesubscriber using subscriber digital telephone 104/106 to dial atelephone number corresponding to the intended destination, selectingthe destination telephone number from an address book associated withsubscriber digital telephone 104/106, selecting the destination phonenumber from a list of recently received and/or placed calls, or thelike. Digital telephone 104/106 uses the destination telephone numberand other such call initiation information associated with the call tocreate a SIP message. The SIP message is transmitted from the broadbandconnection to an Access Session Border Controller (Access SBC) 122located at a server center. Exemplary SBC's include, without limitation,the nCite™ series of Session Border Controllers distributed by Netrakeof Plano, Tex. The Access SBC can act as a first “layer” of the instantsystem and can provide several services to the instant system, includingmonitoring the availability of subscriber phone 104/106. In suchembodiments, calls originating from the subscriber, as well as incomingcalls to the subscriber, can pass through Access SBC 122. In someembodiments, Access SBC 122 can effectuate subscriber digital phoneavailability monitoring by coordinating and processing SIP registrationmessages that are sent from the subscriber digital phones to the instantsystem.

Although the instant system is described herein as comprising a singleAccess SBC 122, it is anticipated that a plurality of Access SBC's 122will be used in many embodiments of the instant system. In someembodiments, one or more subscriber digital telephones 104/106 may beassigned to a specific Access SBC 122. In the case of an Access SBC insuch an embodiment, the Access SBC 122 may comprise a database or otherlist of the unique identifiers associated with each of subscriberdigital telephones 104/106 for which it is responsible. This allowsAccess SBC 122 to limit the number of subscriber digital telephones104/106 with which it must facilitate communication to a number that canbe handled by that Access SBC 122. Because both the Access SBC's 122 andthe subscriber digital telephones 104/106 can be reprogrammeddynamically by merely altering their respective databases, the instantsystem can quickly and easily adapt to hardware-type failures, such asan unexpected failure of one or more Access SBC's 122. The instantsystem can further be dynamically adapted to permit planned maintenanceof one or more Access SBC's without interrupting a subscriber's abilityto place or receive calls. Still further, in some embodiments the AccessSBC assignments may be handled by an intelligent assignment system whichdynamically balances the number of subscriber digital telephonesassigned to, and/or reallocates subscriber digital telephones assignedto, each Access SBC 122 based on the load experienced by each Access SBC122.

When an Access SBC 122 receives a SIP call request from an associatedsubscriber digital phone 104/106, the Access SBC 122 passes the SIP callrequest to a Call Control Node (CCN) 140 via Proxy/SIP Express Router(SER) 130 and load balancer 126. Load balancer 126 allows the callinitiation, call termination, digital telephone registration, and othersuch low-level communications experienced by the instant system to bedynamically spread across a plurality of SER 130′s in the instantsystem, thereby allowing the instant system to provide reliable and fastservice.

In some embodiments, SER 130 can function as a proxy and second “layer”to the instant system, and can direct call requests to CCN 140 based onan identifier associated with the subscriber's user profile. In someembodiments, SER 130 can store a variety of configuration information inCluster Database 136, such as, without limitation, subscriber to CCNassignments, last successful registration of a digital telephone with aCCN, last successful “keep alive” registration message received by SER130 for a digital telephone, subscriber account status and features, andthe like. By way of example, without limitation, a subscriber can beassigned to a specific CCN 140 based on the geographic location of thecaller's billing address, based on route information, or the like. Insome embodiments, the subscriber CCN 140 assignments are made on around-robin basis, thereby providing a level of load balancing in thesystem. In some embodiments, SER 130 can store such assignments inCluster Database 136.

As with Access SBC's 122 and subscriber digital telephones 104/106,because the subscriber CCN 140 assignments are stored in a database(i.e., associated with the subscriber's user profile), the subscriberCCN 140 assignments can be dynamically changed to accommodate plannedand unplanned maintenance or other service interruptions. Still further,in some embodiments the subscriber CCN 140 assignments may be handled byan intelligent assignment system which dynamically balances the numberof subscribers assigned to, and/or reallocates subscribers assigned to,each CCN 140 based on the load experienced by each CCN 140. ExemplaryCCN's include, without limitation, the Synergy line of call controlnodes distributed by Sylantro Systems of Campbell, California. CCN 140is described in more detail below.

The instant system can utilize different call routing schemes dependingon the originator and recipient of a call, and such routing schemes canbe controlled by the Route Management System (RMS) 132 component of SER130. As such, in some embodiments CCN 140 may offload routeidentification and selection to alternative components within theinstant system, such as RMS 132. As described below, RMS 132 is capableof aggregating routing information from a variety of sources such as,without limitation, carriers 112 and MIFFED server 128, to determineavailable routes to a destination. RMS 132 may also comprise a routeselection engine which determines a preferred route from the availableroutes. Such determination can be based on a variety of factorsincluding, without limitation, the number of network “hops” to reach adestination, quality of service metrics associated with each route,rates charged by the carrier(s)NoIP partners(s) involved in processingthe call, network type for the destination, and the like. By way ofexample, if a call is being made to another subscriber of the instantsystem, RMS 132 will automatically select a route which allows the callto be directed to an appropriate Access SBC 122 within the instantsystem. If the call is being made to someone outside the instant system,RMS 132 will route the digital voice data to an external network, suchas PSTN 112 or to a VoIP peer 114.

Once a preferred route is determined, RMS 132 can return this route toCCN 140, which initiates communications with an appropriate TerminationSBC 124. In some embodiments, a group of carrier-facing TerminationSBC's 124 interact with carrier partners who provide access to theirrespective portions of PSTN 112. In some embodiments, interactionsbetween the carrier partners and Termination SBC's 124 may be done overIP networks and utilizing IP protocols, wherein the SIP information isused for call signaling and other functions until the call is receivedby a media gateway in the carrier's domain, at which point the call isconverted by the carrier into a format appropriate for PSTN 112.Communication with direct VoIP peers can be similarly handled via aTermination SBC 124. In some embodiments, interactions between directVoIP peers is done over IP networks, as described below.

CCN 140 can be seen as a third “layer” to the instant system. CCN 140can handle all call set up/tear down functions and establish connectionsbetween the originating caller, the appropriate network, and thereceiving caller. CCN 140 can also keep track of call states within theinstant system, validate that call requests are coming from activesubscribers, and other such functions. Once call initializationsignaling is complete and a call is successfully set up, transmission ofthe digitized conversation can take place.

CCN 140 can coordinate and provide signaling that facilitates thecompletion of incoming calls from external systems and networks. In someembodiments, a call from PSTN 112 can be converted to a SIP callrequest, which is transferred to the instant system by way of a carrierfacing Termination SBC 124. The SIP call request can be transferred fromthe Termination SBC 124 to CCN 140 by way of SER 130. As part of thetransfer between SER 130 and CCN 140, the CIS component 134 of SER 130can associate information from a caller information service, such as,without limitation, caller ID information, caller name, calling partynumber, and the like, with the SIP call request. These functions can besupported by the ability of CIS 134 to query third party services 144 toacquire such information. By way of example, without limitation, CIS 134can obtain the caller name for Caller ID purposes by querying thirdparty service 144 and supplying the telephone number associated with theincoming call which is received as part of the SIP signaling messagegenerated by Termination SBC 124 when carrier 112 passes a call to theSBC. CIS 134 can, in turn, insert the Caller ID information into the SIPsignaling messages, and the amended SIP signaling messages can be passedto the CCN by SER 130.

CCN 140 can also route to voicemail any unanswered incoming calls,assuming voice mail has been activated by the subscriber. Such voicemailservices may be provided by a CCN, or by an external voicemail serviceprovider 109. In some embodiments, CCN 140 comprises software that runson one or more general purpose servers within the instant system, suchas the suite of call control software distributed by Sylantro Systems.

Once an outgoing call request is successfully processed throughcomponents of the instant system and a call is set up, the digital voicedata for the call is sent from subscriber digital phone 104/106, throughsubscriber's broadband connection to the Access SBC 122 associated withthe subscriber. From there, if the call is to another subscriber of theinstant system, the caller's Access SBC routes the voice data directlyto the destination subscriber's Access SBC 122, which in turn routes thevoice data to the destination subscriber's digital telephone. If thecall is to a party who is not a subscriber to the instant system, thesubscriber's Access SBC can route the call directly to an appropriateTermination SBC 124, if such Termination SBC's are present in thesystem. In embodiments where Termination SBC's are not used between theinstant system and VOIP Peers 114, the voice data may be relayed fromthe subscriber's Access SBC directly to an appropriate VOIP peer. In theevent a call is directed to a person who is also using VoIP but is not asubscriber to a VoIP Peer 114, the call can be routed to the person byway of Termination SBC 124 and an appropriate carrier 112.

Unlike calls to subscribers on non-peer networks, which must be routedthrough PSTN 112, calls routed to peered VoIP providers stay in apacketized form. This allows a variety of call-related information to bepreserved and utilized throughout the call, and allows the instantsystem to take advantage of advanced features enabled by the digitalnature of the voice data.

Each conventional VoIP provider or VoIP peering exchange servicetypically implements their own ENUM tree, because it is assumed that allcalls outside the VoIP provider's network will be routed through thePSTN. However, the instant system allows for the interoperation of aplurality of VoIP providers, and as a result, utilizing information fromthese multiple traditional ENUM architectures can become problematic.

As described above, ENUM trees are defined in Internet EngineeringTaskforce Request for Comments 3761, and SER 130, which comprisespublicly available software designed to provide VoIP routing byleveraging such ENUM trees, has been implemented with the assumptionthat only one ENUM tree is available. This assumption significantlyhampers a VoIP provider's ability to peer with other VoIP providers. Theinstant system overcomes this inherent shortcoming by providing amultiplexing proxy daemon (which can be implemented as part of MIFFEDServer 128) that appears to SER as though it were a standard cachingnameserver but which in fact synthesizes an answer set based on queriesfrom multiple ENUM trees accessible to the server.

This architecture raises a complication that is inherent to usingmultiple ENUM trees. In many cases a query to two or more ENUM treeswill result in ambiguous results about how a caller should interpret thecombined results when there is no coordination between the trees. By wayof example, without limitation, if two ENUM trees have a record for aparticular telephone number and they both have the same Priority butdifferent Rewrite fields, then the SER component could end up routingthe call randomly between two different SIP providers. The conventionalENUM rule for dealing with records with the same Order and Preference isto pick randomly, thereby providing a rudimentary load balancingmechanism. By contrast, some embodiments of MIFFED Server 128 allow ENUMtrees to be ranked within the MIFFED configuration. Thus, if one ENUMtree is ranked above another, then the preference value for any NAPTRrecords from the higher ranked ENUM tree will be rewritten so that theresulting preference value is higher than any NAPTR returned from anylower ranked ENUM tree. In the case where no preference is provided theMIFFED server will issue a non-fatal configuration warning and willforward the unchanged NAPTR set.

One task of MIFFED server 128 is to multiplex at least two ENUM treesinto a one so that a SER instance still views the world as having onlyone ENUM tree to query. Since ENUM can be seen as a set of conventionsfor using the Domain Name Service (DNS) protocol, this task breaks downinto two distinct parts: compliant DNS behavior and compliant ENUMbehavior.

Although it can be assumed that the querier is a SER instance, whichimplies that the querier may not require MIFFED Server 128 to possessfull DNS functionality, there are particular ways in which any basic DNSserver must behave. This includes reporting error codes correctly,gracefully refusing EDNSO queries, and dealing with incorrectlyconfigured/implemented clients. In addition to the basic DNS behavior,certain ENUM-specific semantics should be supported to implement themulti-tree ENUM server in MIFFED Server 128. Such semantics include,without limitation, correctly rewriting preference values to denoteranked ENUM trees, dealing with incorrect ENUM responses from thirdparty ENUM trees, and allowing for future development to take advantageof rewriting other NAPTR fields.

FIG. 2 illustrates a traditional SER ENUM process flow. In FIG. 2, SBC200 queries CCN 220 by way of SER Director Proxy 210. SER Director Proxy210 first queries CCN 220 to determine whether the telephone number isone serviced by the instant system. If the request is for a telephonenumber serviced by the instant system, then SER Director Proxy 210requests appropriate call control information from CCN 220. If thetelephone number is not one serviced by the instant system, SER DirectorProxy 210 queries the ENUM tree of Caching DNS Server 230, whichmaintains an internal ENUM tree.

FIG. 3 illustrates an alternative SER ENUM process flow that is capableof multiple, parallel ENUM queries to multiple peering partners. In FIG.3, SBC 200 queries CCN 220 by way of SER Director Proxy 210 to obtainrouting and other call-related information. SER Director Proxy 210 inturn queries CCN 220 to determine whether the telephone number beingcalled is one serviced by the instant system. If the request is for atelephone number serviced by the instant system, then SER Director Proxyrequests appropriate call-related information from CCN 220. If thetelephone number is not one serviced by the instant system, SER DirectorProxy 210 queries the ENUM tree of a plurality of Caching DNS Servers230, each of which maintains an internal ENUM tree for its network. SERDirector Proxy 210 can then determine which of the peering partnersservices the telephone number and can obtain additional information fromsuch VoIP peering partners. Appropriate information is then returned toAccess SBC 200, which begins forwarding the call-related IP packetsbased on the information.

FIG. 4 illustrates an alternative SER ENUM process flow capable ofmultiple, parallel ENUM queries to multiple peering partners. In FIG. 4,SBC 200 queries CCN 220 by way of SER Director Proxy 210 to obtainrouting and other call-related information. When SER Director Proxy 210receives the request on behalf of CCN 220, SER Director Proxy 210 canqueries CCN 220 to determine whether the telephone number is oneserviced by the instant system. If the request is for a telephone numberserviced by the instant system, then SER Director Proxy 210 requestsappropriate call-related information from CCN 220. If the telephonenumber is not one serviced by the instant system, SER Director Proxy 210queries MIFFED Server 240. MIFFED Server 240 can simultaneously, ornearly simultaneously, poll a plurality of Caching DNS Servers 230, eachof which maintains an ENUM tree for its respective VoIP peering partner.MIFFED Server 240 may also obtain routing data from one or morecarriers. As described above, MIFFED Server 240 can handle organizingthe various routing information and any conflicts therein. MIFFED Server240 can then provide appropriate call-related information to SERDirector Proxy 210 which can forward the information to CCN 220, alongwith any preference or priority attributes associated with each route.CCN 220 can, in turn, provide the selected route to Access SBC 200 viaSER Director Proxy 210. Access SBC 200 can then begin forwarding thecall-related IP packets based on the routing information.

In the embodiment illustrated in FIG. 4, MIFFED Server 240 may rely onstandard DNS fault tolerance mechanisms. The SER ENUM module can begiven an ENUM tree name which will use two or more name server (“NS”)records in the authoritative DNS to point at MIFFED server instances(e.g., separate MIFFED Servers 250). If a MIFFED instance fails, theoperating system DNS routines of the querying machines will thereforefail over to another, operative MIFFED instance.

In some embodiments, MIFFED Server 240 will not contain full DNSresolution or caching functionality. Instead, each MIFFED Server 240instance can sit in front of a standard DNS full-resolving cache such asBIND or DNSCACHE, as illustrated in FIG. 5.

In some embodiments, configuration parameters associated with eachMIFFED Server 240 will be periodically read from a database by theMIFFED Server. This will allow Ops Portal 176 to easily update theMIFFED Server configurations should it be necessary, including, withoutlimitation, the disabling of queries directed to specific ENUM trees. Italso allows an individual MIFFED Server 240 to recover from anyunintentional or malicious data corruptions occurring at the server withonly minimal impact on the system as a whole.

In some embodiments, MIFFED Server 240 can translate ENUM tree namesfrom a source to a destination and back. That is, if a query for8.9.6.6.8.4.3.7.1.9.1.e164.arpa is sent by SER Director 210, a MIFFEDServer 240 multiplexed query should be changed to match the destinationtree name such as 8.9.6.6.8.4.3.7.1.9.1.thevpf.com, and vice versa. Insome embodiments, non-ENUM tree queries should flow through the MIFFEDServer 240 unimpeded, but some embodiments of MIFFED Server 240 may logsuch queries as an error. MIFFED Server 240 may wait a fixed period forthe results of ENUM queries before the query times out. If a query timesout, any collected answers can be returned without waiting on responsesfrom any additional ENUM trees. If no answers have arrived with in theprescribed duration, an RCODE 3 error can be returned. Any receivedRCODE 3 errors can be ignored if any other set of queries yielded apositive result.

In some embodiments, MIFFED Server 240 can change NAPTR preferencevalues on collected answers, thereby allowing a service provider orother implementer of the instant system to rank ENUM trees bypreference. In some embodiments, ENUM trees lacking a specificpreference can receive the lowest available preference by default.

In some embodiments, each instance of MIFFED Server 240 can keepstatistics data and expose this data via Simple Network ManagementProtocol (SNMP). To help reduce storage an other requirements, thestatistics data may be limited to data covering a fixed period of time,such as the preceding 5 minutes of operation and/or preceding 24 hoursof operation. Such statistics may include, without limitation, thenumber of source ENUM queries (queries from SER), the number ofdestination ENUM responses that are positive, the number of destinationENUM responses that are negative, the number of answer sets containingat least one positive answer, the number of answer sets containing nopositive answers, the number of destination ENUM timeouts, and thenumber of non-ENUM source queries. In some embodiments, MIFFED Server240 may comprise a configuration option which allows the statistics tobe written to a log, if such a log is enabled. In some embodiments,MIFFED Server 240 may also log every destination ENUM timeout as anerror. In some embodiments, MIFFED Server 240 may track the number ofpositive answers from each destination ENUM tree, as well as the totalnumber of server timeouts from each destination ENUM tree.

Some embodiments of MIFFED Server 240 may be implemented with a databaseabstraction layer, such as that provided by the Hibernate Java library,thereby allowing MIFFED Server 240 to access data stored in a variety ofdata formats and databases. Some embodiments of MIFFED Server 240 may bewritten in Java conformant to the 1.5 JDK (Java 5), and may rely onseveral standard Java libraries, including, without limitation, thefollowing libraries:

java.nio.—Because embodiments of MIFFED Server 240 can be seen asmultiplexing forwarders, such embodiments of MIFFED Server 240 will needto listen on many ports simultaneously. This can be accomplished usingjava.nio and selectors.

Spring—MIFFED Server 240 can use the Spring framework to glue thevarious modules together.

Dnsjava—MIFFED Server 240 can utilize this library to provide the DNSwire protocol conversion methods.

Log4j—Log4j can facilitate the data logging described herein.

JMX—This library can allow MIFFED Server 240 to support SNMP.

Some embodiments of MIFFED Server 240 will comprise software, which canbe encapsulated into separate JARs based on the functionality associatedtherewith. Examples of such JARs include, without limitation:

Server—the classes for running MIFFED Server 240.

Support—classes that can be used to read and write configurationinformation in the database and read and write statistics information inthe database.

Client—classes that can create ENUM queries for diagnostic purposes.

Referring again to FIG. 1, the instant system also comprises a pluralityof back-end processing components 160. The functionality of thesecomponents will be described in more detail the following examples.Although illustrated and described herein as discrete components, it isspecifically contemplated that the functions described herein can becombined into one component, or diversified across additionalcomponents, and that such changes would not depart from the spirit orthe scope of the instant highly scalable IP-based communication system.

The back-end processing components are perhaps most easily described interms of two examples. A first example is the registration process thatmight be experienced by a new subscriber. A second example is a means bywhich the digital telephones can be managed. These examples are providedfor the purposes of illustration, and are not intended to limit theinterpretation of the disclosed highly scalable IP-based communicationsystem or the appended claims.

To begin using the instant system, a prospective subscriber can visit aworld wide web site (“web site”) 162 associated with a service providerimplementing the instant system to indicate his or her desire toinitiate service with that service provider. In some embodiments, if theprospective subscriber does not currently have a digital telephone, theservice provider may provide such a device at a reduced price in aneffort to induce new subscribers. The new subscriber will click on orotherwise interact with portions of web site 162 to initiate the sign-upprocess (illustrated in FIG. 1 as sign-up 166). As part of the sign-upprocess (also referred to as customer activation workflow 172), thecustomer enters a variety of information. Such information may include,but is not limited to, a credit card number or other paymentinformation, a billing address, the customer's name, a desired serviceplan, the MAC address or other unique identifier associated with asubscriber device (if the prospective subscriber already has such adevice), and the like. Once entered, the customer's information can bestored in customer database 170. In some embodiments, customer database170 is separate from customer info databases 142 and separated from thenetworking equipment 120 by one or more firewalls or other securitydevices. This allows customer database 170 to house more sensitiveinformation, such as customer billing information, calling patterns, andthe like. Billing system 168 may verify any credit card or other paymentinformation through one or more credit card processors 190 prior toactivating the prospective subscriber's account.

In some embodiments, once the prospective subscriber's account isactivated, the subscriber can utilize Member Portal 164 to access avariety of subscriber-accessible functions. Such functions may beprovided by Façade 174, which in some embodiments can provide anAPI-like interface through which both service provider operators andsubscribers can access various components of the instant system. By wayof example, without limitation, Façade 174 may allow a subscriber tomodify his or her account information (which may be stored in CustomerDatabase 170), view call logs (which may be stored, for example, inCustomer Info Databases 142), access voicemails (which may also bestored, for example, in Customer Info Databases 142), review textmessages addressed to the subscriber and received by the instant system(such messages may also be stored in Customer Info Databases 142),add/remove the digital telephones associated with the subscriber'saccount, and the like by way of Member Portal 164. The use of anAPI-like interface such as Façade 174 can be advantageous as it allowsthe underlying components to be replaced with other, alternative and/oradvantageous components, without necessitating the rewriting orreconfiguration of member portal 164, or any of the sign-up componentsand workflow.

As illustrated in FIG. 10, if a new subscriber does not have a digitaltelephone at signup 1000, the service provider can provide one (block1010). In such instances, the service provider can obtain the MACaddress or other unique identifier associated with the digital phoneprior to shipping and store this in customer database 170 and/orcustomer info database 142 of FIG. 1. In some embodiments, customerdatabase 170 and customer info database 142 may contain duplicativeinformation. Although this increases the overall system storagerequirements, the duplicative information can be advantageous in theevent of accidental or malicious data corruption.

Referring again to FIG. 10, when the subscriber receives his or herdigital telephone, the subscriber can simply plug digital telephone 1020into a power outlet and the broadband connection. Once digital telephone1020 boots, it can obtain an internet protocol address (IP address) andrelated configuration information dynamically from a Dynamic HostConfiguration Protocol (DHCP) server or the like, thereby allowing thedigital telephone to begin accessing the Internet via the broadbandconnection. In some embodiments, if a DHCP or equivalent server is notavailable, the digital telephone may request the necessary informationfrom the subscriber. In some embodiments, the digital telephone may bepre-configured to request additional configuration information from afixed address, such as, without limitation,http://www.sunrocket.com/gms/[type]/MacAddress/CFG/, wherein [type] is adevice type identifier associated with the digital telephone. In someembodiments, the digital telephone may include a Universal Serial Bus(USB) port or other such communications port, and the subscriber mayconnect the digital telephone to his or her computer and, through theuse of specialized software, allow the computer to provide such initialconfiguration settings to the digital telephone without the need for thedigital telephone establishing a link via the broadband network.

In some embodiments, Gizmo Management System (GMS) 178 of FIG. 1 canmanage digital telephone requests for configuration information, collectstatus information on deployed digital telephones, and perform othersuch functions. GMS 178 of FIG. 1 and GMS 1060 of FIG. 10 areequivalents and provide similar functionality. GMS 1060 can respond to aconfiguration request from the digital telephone and authenticate therequest based on the MAC address or other unique identifier associatedwith the digital telephone. GMS 1060 may also request or receive acredential from the digital telephone. Such a credential can be verifiedagainst information stored in Customer Database 170 and/or Customer InfoDatabase 142 of FIG. 1 thereby further authenticating the digitaltelephone to the instant system. GMS 1060 can provide a variety ofinformation to the digital telephone in response to a configurationrequest including, without limitation, the phone number to be associatedwith the digital telephone, a SIP identifier to be associated with thephone, a SIP password, and the Access SBC with which the digitaltelephone is to be associated. In some embodiments, GMS 1060 comprises aweb server, and can provide the configuration information as anextensible markup language (XML) document, Hypertext markup language(HTML) document, or the like via hypertext transfer protocol (HTTP) orother similar or successor protocols. The digital telephone and GMS 1060may employ SSL or other encryption as part of the HTTP communications,thereby allowing both the digital telephone and GMS 1060 to authenticatethe information provided. In some embodiments, the configurationinformation may be encrypted and/or digitally signed using a sharedpassword, public key encryption, or the like. In embodiments employingshared passwords, the digital telephones may permit the service providerto designate a new password as part of a configuration file. In suchembodiments, the service provider may periodically change the passwordto help maintain overall system security. In some embodiments, GMS 1060can be implemented as a Java Servlet. A Java Servlet is softwareexecuted by a web application server in response to a request for aresource. Java Servlets typically access databases to generateresponses, rather than merely transferring static data files. Such aconfiguration can allow GMS 1060 to ensure that the most currentinformation is provided to the digital telephone in response to eachconfiguration information request.

In some embodiments, each time a digital telephone is rebooted thedigital telephone initiates a re-registration process, wherein such are-registration process may comprise obtaining the latest configurationinformation from GMS 1060 and then initiating the registration processesdescribed above. Similarly, any time an operator or administrator of theinstant system wishes to force a digital telephone to update itsconfiguration, Telegraph 1050 can issue a SIP NOTIFY notice, using theinformation contained in proxy cluster DB 1040, which is the equivalentof cluster DB 136 of FIG. 1, to the digital telephone. The receipt of aSIP NOTIFY message by the digital telephone forces the digital telephoneto obtain the latest configuration data. In some embodiments, the SIPNOTIFY message must be properly signed and/or authenticated for thedigital telephone to update the configuration information. In someembodiments, a SIP NOTIFY message can force the digital telephone toreset itself to factory defaults or to other settings that areincompatible with the service provider, there by effectively disablingthe digital phone.

Referring again to FIG. 1, in some embodiments, Ops Portal 176 of FIG. 1can provide an interface through which operators or administrators viewand search customer database 170 and/or customer information databases142 and use Telegraph 180 to notify digital telephones, selectively orcollectively, to reload their configurations, refresh or updatefirmware, and perform other such maintenance tasks. To facilitate suchfunctionality, customer database 170 and/or customer informationdatabases 142 may contain a variety of information about each digitaltelephone associated with the instant system, including, withoutlimitation:

-   MAC Address (which is used as the primary key for each database    entry)-   Phone number-   Device type-   Current firmware revision-   Configuration template (overrides default template)-   Last download timestamp-   Last download response-   Last registration timestamp-   Encryption flag-   Encryption pass phrase-   Configuration settings (remote login, current codec used, and the    like)-   Modification timestamp (set when configuration is changed)-   Outbound Proxy Address (also referred to herein as the Access SBC)-   Registration Proxy Address (also referred to herein as the RMS)-   Support queries by hardware manufacturer, software revision,    account, phone number

Ops Portal 176 also allows operators or administrators of the instantsystem to reconfigure digital telephones as needed. In some embodiments,Ops Portal 176 provides a portal through which an operator oradministrator can alter a variety of settings for an individual digitaltelephone or for a set of digital telephones. Such settings include,without limitation, the Access SBC to which the digital telephone isassigned, the CCN to which the digital telephone is assigned, the sharedpassphrase/password, the software and/or firmware version to beinstalled, and subscriber-specific settings such as enabling/disablingaccounts, enabling/disabling voicemail for the account, and the like.

To take advantages of the features and functions of the instant system,a digital telephone must register with the system. In addition, toenable both incoming and outgoing calls for digital telephones behindfirewalls and to make sure any IP address change conducted by the ISPnetwork at the subscriber location is quickly discovered, the digitaltelephone must periodically communicate with the instant system. If suchperiodic communications do not occur, many firewalls will close the portassociated with incoming communications from the instant system or theISP may dynamically change the subscriber's IP address, therebyrendering the digital telephone unable to receive incoming calls andother notifications. To accommodate digital telephones behind suchfirewalls and for other such purposes, some embodiments of the instantsystem, by default, can instruct the digital telephones to re-registerperiodically. In some embodiments, the re-registration period may be afixed amount of time, such as thirty seconds. In some embodiments, whenthe digital telephone first registers with the instant system, thedigital telephone and instant system can determine a maximumre-registration period for that individual digital telephone'senvironment by incrementally increasing the re-registration period untilthe digital telephone no longer receives responses from the instantsystem. In such embodiments, the re-registration period can then bedecreased to a known successful re-registration period.

Digital telephone re-registration can be problematic, as traditionalCCN's are not configured to concurrently handle the volume of incomingSIP registration messages that are generated as a result of suchre-registrations. In some embodiments, such as the embodimentillustrated in FIG. 1, Access SBC 122 and SER 130 are configured tohandle such re-registration requests, thereby offloading some of theworkload from the CCN's.

FIGS. 6 and 7 illustrate an exemplary process by which suchregistration/re-registration messages can be handled by the instantsystem. In FIG. 6, when a registration message is received by a SER(Block 600), the SER extracts information from the SIP registrationmessage including, without limitation, the phone number or serviceaddress of the device sending the registration message, the device IPaddress and the port on which the device will be listening for responsesfrom the instant system, the expiration period for the request, and thedevice user agent (Block 605). If a service address or phone numbercannot be successfully parsed from the registration message, theregistration request is dropped (Block 615). If the service address ortelephone number can be parsed, then the device registration data isread from the cluster database (cluster database 136 of FIG. 1). If thedatabase contains an entry for the device, then an insert flag is set tofalse and the processing proceeds to block 665, described below. If thedatabase does not contain an entry for that device (Block 625), then theinformation associated with the service address or telephone is readfrom the cluster database (Block 635). If the service address ortelephone number is not known to the system (Block 640) then the requestis recorded in a log (Block 645), and the instant system can return a“Not Found” message to the device making the registration request (Block650). If the service address or telephone number is one known to thesystem (i.e., one for which there is a subscriber), then the insert flagis set to true (Block 655) and the address ID, node ID and user agentare obtained from the cluster database (Block 660).

In Block 665, the SER parses the registration request to obtaininformation. Such information may include, without limitation, contactinformation, a call identification checksum, the expiration for therequest, the user agent, and the record-route. Processing then continuesin Block 670 of FIG. 6, which is illustrated in FIG. 7 as Block 700.Blocks 705 and 710 are duplicative of Block 670 of FIG. 6, andillustrates the collection of information by parsing the registrationrequest. In Block 715, the SER polls the cluster database to determinewhether a valid registration exists for the digital telephone making theregistration request. If there is a valid registration, the deviceregistration record is updated in the database (Block 720), therebyindicating that the device successfully re-registered. Additionalinformation may also be stored in the cluster database (Block 720). TheSER then sends a “SIP 200 OK” message to the digital telephone inresponse, thereby indicating to the digital telephone that there-registration was successful. Upon successful re-registration, thedigital telephone can cease sending re-registration requests for a fixedperiod of time, such as, without limitation, 30 to 45 seconds. In someembodiments, if a response is not received to the re-registrationrequest within a fixed timeout period, such as 500 milliseconds, there-registration request may be re-sent. If the second re-registrationalso goes with out a reply, the digital telephone may be configured tobegin sending re-registration requests at longer intervals, such asevery two to four seconds.

Referring again to block 715, if the cluster database does not include avalid registration then the SER can determine whether an authenticationheader is present in the registration request (Block 735). The SER canalso compute the offset between the expiration of the registrationrequest and the current time stamp (Block 740). If an authenticationheader is not present, then the SER can assume that the registrationrequest is for a new digital telephone and can make appropriate entriesin the cluster database (Block 755). If the authentication header ispresent, then the SER can assume that the registration request is for apreviously registered digital telephone, and the information in thecluster database about that digital telephone may be updated asnecessary (Block 750). The registration request information may bemodified by the SER to include the port and name or other identifier forthe SER, such that the CCN, can properly route information to theappropriate SER (Block 760 and 765). The registration information canthen be forwarded to a CCN (Block 770).

In some embodiments, the SER may only pass registration requests for aspecific digital telephone to a CCN after a certain timeout period hasexpired since the previous registration request for that digitaltelephone was processed by a CCN. This process is described in moredetail, below. FIG. 8 illustrates a method by which a SER can update thecluster database based on information received from a CCN once the CCNhas been passed a registration request. In FIG. 8, the SER has modifiedthe incoming registration request and substituted the SER's address andport information for that of the digital telephone, thereby allowing theSER to act as a proxy for the registration request, and ensuring thatthe SER can update the cluster database as necessary.

In FIG. 8, upon receipt of information from the CCN, the SER extractsthe service address, telephone number, or other such identificationinformation from the registration request (Block 800). The deviceregistration results are then read from the cluster database for thedevice associated with the service address, telephone number, or thelike extracted in Block 800 (Block 805). If the CCN returned a SIPstatus code of 200 (Block 810), the digital telephone was successfullyregistered and authenticated with the CCN and the cluster databaseregistration record for the digital telephone is updated to a status ofSUCCESS (Block 815), after which processing proceeds to Block 840(described below). If the status code is a 401 (Block 820), then thedigital telephone needs to reauthenticate with the CCN, and thisinformation is recorded in the cluster database (Block 825), after whichprocessing proceeds to Block 840. If the CCN did not return a SIPmessage status of 200 or a SIP message status of 401 (Block 830), theCCN has indicated that there was an error of some sort (e.g., an attemptto register a device that is not authorized to use the instant system)and the cluster database is updated to indicate a status of FAIL forthat digital telephone. The SER modifies the header of the incomingmessage from the CCN and replaces the SER's information (e.g., headerand port) with the information of the digital telephone (Block 840) andupdates the expiration period with the original expiration periodreceived from the digital telephone (Block 845). This modified messageis then forwarded to the appropriate Access SBC for forwarding to thedigital telephone.

FIG. 9 illustrates the insertion of SER 130 as a proxy between an AccessSBC and a CCN. In FIG. 9, a Termination SBC has initiated a call from acarrier partner or VoIP peer, and that request has been sent to a CCNfor processing. The CCN has already determined that the telephone numberassociated with the call request corresponds to a subscriber of theinstant system, and attempts to connect the call. However, as describedbelow, the CCN's database may not be up to date with respect to thedigital telephones currently serviced by the instant system. The SERproxy contains a more accurate list, and when the SER proxy receives therequest from the CCN, the SER proxy first extracts the user portion ofthe request (Block 900) and searches the cluster database to determinewhether a corresponding digital telephone has been registered (Block905). If the a corresponding device has been registered (i.e., a recordis found in the cluster database), then the request is rewritten suchthat the request contains the digital telephone's IP address or othersuch information (Block 920), and the header is amended such that therequest is routed to an appropriate Access SBC (Block 925). The modifiedrequest is then forwarded to the Access SBC for processing (Block 930).

In some embodiments, when an Access SBC receives a registration request,the Access SBC will reply with a SIP status message of 200 or otherwiseindicate that the registration request is successful if the registrationrequest is from a digital telephone whose last successfulregistration/update with the SER layer was less than 60 minutes or otherconfigurable time period ago. If the registration request is from adigital telephone whose last registration/update with the SER layer wasmore than an hour ago, the Access SBC will forward the registrationrequest to the SER layer. As described above, if the SER layerdetermines that the registration request is from a previously registereddigital telephone, and if the digital telephone was last authenticatedagainst the CCN less than twenty-four hours ago, then the SER layerindicates to the Access SBC that the registration request wassuccessful, and the Access SBC in turn returns this information to thedigital telephone. Where the digital telephone was last authenticatedagainst the CCN more than twenty-four hours or other configurable timeperiod ago, the SER layer passes the registration request to the CCN andpasses the result back to the Access SBC (as described above withrespect to FIG. 8).

In some cases, such as, by way of example without limitation, where acommunications failure shuts down access of the instant system to theInternet, or where a specific Internet Service Provider has hardware orsoftware problems, the instant system may be flooded with registrationrequests. Some embodiments of the instant system can employ a novelmethod of handling such registration requests, which is described below.In such embodiments, a hashing algorithm can be applied to evenlydistribute the registration requests over a larger time window. Whensuch registration requests are received by an Access SBC, the Access SBCmodifies the header such that the header has an expiration periodgreater than or equal to that expected by the SER, and forwards theregistration request to a SER. The SER can then determine whether theregistration request should be passed to the CCN and, if theregistration should be passed to the CCN, the SER can modify the requestsuch that it has an expiration period greater than or equal to thatexpected by the CCN. The modified request is then forwarded to the CCN,which in turn processes the request and returns a result to the SER. TheSER can then modify the result such that it is routed to the appropriateAccess SBC, and such that it contains a preferred expiration time.

In some embodiments, this preferred expiration time can be randomlychosen within a max_period, wherein the max_period value comprises themaximum period, in seconds, that the SER is authorized to authenticatesincoming registration requests before forwarding them to a CCN forauthentication. Such a random selection can distribute thereregistration requests.

While random redistribution can be effective, in some embodiments, thepreferred expiration time can be computed by assigning each deviceregistration record a unique, monotonically increasing, integer primarykey, referred to herein as a registration id (abbreviated as reg_id).The reg_id is assigned when the device registration record is initiallyinserted in the cluster database, and an expiration slot is calculated.An expiration slot is a portion of the max_period during which thatparticular digital telephone should initiate any registration requests.In some embodiments, the expiration slot for a device is fixed withinthe max_period window by taking the modulo of the reg_id by themax_period value. The SER can then manipulate the expires value inrequests sent to the CCN's and responses forwarded to the Access SBC'sbased on the slot, so that requests are distributed across themax_period window. In some embodiments, the SER calculates the endingdate-time of the registration period and stores it with the deviceregistration record in the cluster database when the request isforwarded to the CCN. This can become a hard limit to the registration'svalidity. The SER can also store in the cluster database the most recentdate-time that the CCN acknowledged a register request with a SIP 200 OKresponse. The SER can then calculate two offsets to determineregistration validity: the time elapsed since the most recentregistration and the time remaining until the hard limit. This providesa range within which the registration is valid. A hash methodology isalso applied to the request from the Access SBC. Assume the sbcperiod(that is, the period at which the proxy expects to receive registerrequests from the Access SBC) is 14400 (4 hours). The interval betweenthe current request and the device's slot is then calculated. If it isless than sbc_period, the Proxy can use the difference (for example,1250 seconds) when it rewrites the SIP 200 response rather than the14400 it received from the Access SBC, thereby instructing the AccessSBC to forward the next request 1250 seconds later. This has the effectof aligning register requests with a preferred “slot”, or interval inthe sbcperiod, during which that digital telephone is to issue registerrequests. This allows register requests to the SER from the Access SBCto be evenly distributed across the maxperiod window due to modulo hashused to calculate each slot.

While detailed and specific embodiments of the disclosed highly scalableIP-based communication system have been described herein, it will beapparent to those skilled in the art that various changes andmodifications can be made therein without departing from the spirit andscope of the instant system. Thus, it is intended that the presentdisclosure cover these modifications and variations provided they comewithin the scope of any appended claims and/or their equivalents.

What is claimed is:
 1. A method of relaying telecommunicationinformation, comprising: receiving by a proxy call control informationfrom a first IP-based telecommunications device, wherein the callcontrol information includes a sender address, a destination identifier,and a destination address associated with the proxy; recording thesender address in a database; modifying the call control information toreplace the sender address with the address associated with the proxy;forwarding the call control information to a call control node togenerate information to facilitate communication between the firstIP-based telecommunications device and a second IP-basedtelecommunications device, wherein the second IP-basedtelecommunications device is associated with the destination identifier,and wherein the information generated includes an address associatedwith the second IP-based telecommunications device; modifying the callcontrol information by replacing the destination address with theaddress associated with the second IP-based telecommunications device;and forwarding the modified call control information to the secondIP-based telecommunications device.
 2. The method of claim 1, whereinthe modifying of the call control information further comprisesreplacing the sender address with the sender address recorded in thedatabase.
 3. A method of relaying telecommunication information,comprising: receiving a request to initiate a telecommunications sessionbetween a caller and a destination via a proxy, the request including acaller telephone number and a destination telephone number; recording ina database an address associated with the telecommunications sessioninitiation request; modifying the telecommunications session initiationrequest to create a first modified request appearing to come from theproxy; forwarding the first modified request from the proxy to a callcontrol node; receiving from the call control node information tofacilitate communication between the caller and the destination, whereinthe information comprises an address associated with the destinationtelephone number, and wherein the information is received by the proxy;modifying one of the telecommunications session initiation request andthe first modified request to create a second modified request, whereinthe second modified request appears to be coming from the sender; andforwarding the second modified call control information to thedestination telephone number.
 4. A method of relaying telecommunicationinformation, comprising: receiving a request by proxy to initiate atelecommunications session between a caller and a destination; recordingin a database an address associated with the telecommunications sessioninitiation request; modifying the telecommunications session initiationrequest to create a first modified request, wherein the first modifiedrequest appears to be coming from the proxy; forwarding the firstmodified request from the proxy to a call control node; receiving fromthe call control node information to facilitate communication betweenthe caller and the destination, wherein the information comprisesrouting information, and wherein the information is received by theproxy; modifying one of the telecommunications session initiationrequest and the first modified request to create a second modifiedrequest, wherein the second modified request appears to be coming fromthe caller; and forwarding the second modified call control informationto the destination utilizing the routing information.